An interview with Jim Hoffman

by Douglas Reilly

To say that Jim was a database geek [when we worked together] is an understatement. He was the guy who wrote stored procedures to write stored procedures.

I met Jim Hoffman a number of years ago when he hired me at SportSoft Golf, one of a million dot-com companies that rolled over and played dead a couple of years after being purchased by another company.

I had been employed by a healthcare system, then a home healthcare software development firm, and my experience was in creating ASP intranet applications that replaced fat client applications. Transitioning to an Internet company from the healthcare industry was a shocking experience. I was not accustomed to the breakneck speed at which things moved. Working with Jim made the experience much more pleasant.

I know some people who worked with Jim bemoaned the fact that he wanted to do everything in the database. I found that his balance was about right, however, since we were using Classic ASP and VBScript. Under those circumstances, having any functionality you could on the database server is a good idea.

Jim is now a reformed geek. As chief operating officer of Innovative Health Solutions, a company that creates web-based solutions for healthcare providers, he is as comfortable and competent in a non-technical setting as he was as a developer. I can’t say for sure, but I imagine Jim has SQL Server client tools installed on whatever PC he uses.

Jim answered the following questions via email.

Doug: How did you become involved in database work?

Jim: In the early 1990s, the company for which I worked was developing software using PC/FOCUS, which did not support databases greater than 256 MB. Keeping in mind that high-end servers came with 4 MB of RAM back then, it wasn’t as bad as it sounds. Still, we found ourselves working harder to get around the limit, and we started to look at other options. Microsoft released its first version of SQL Server around this time-a Wintel port to Sybase-and I got in on the ground floor.

Doug: You were involved in some early work on SQL Server. What do you think have been the greatest differences in the product from then to now?

Jim: The optimizer is smarter. The tools are better. The profiler, especially, has seen continuous improvement. It may be SQL Server’s most underappreciated development tool.

There are some significant non-technical issues as well. The development community for SQL Server in the mid-1990s was relatively small, and there was more access to technical staff at Microsoft. You could easily get a same-day customized patch if you discovered a critical bug, for example. As SQL Server has grown more popular, things have changed by necessity. The flip side is that with the almost simultaneous growth of the Internet, there are more resources available to the developer or DBA.

Doug: One of the things that I recall from our work together was that we had four web servers hitting a single, underpowered SQL Server database server, but things ran pretty well. Do you have any advice for people interested in creating a scalable application?

Jim: The most important advice is to be sure you have the right hardware configuration. I’ve seen people with very powerful servers configured in ways that are inappropriate for their SQL Server application, and in ways that put their data at more risk than is necessary. Luckily, many server manufacturers now have white papers recommending ways to set up SQL Server on their hardware.

Doug: What made you decide to move away from a purely technical position?

Jim: I’ve always liked change. I moved into a technical position after being in a financial analyst role right out of college. In college I originally majored in engineering, and then switched to economics. It may be that a mostly non-technical role in a technology company is the best fit for me.

Doug: With a non-technical role in a mostly technical organization, how hard is it to let other people do things-especially things you think you could do better?

Jim: It’s hard, but I’ve gotten better at it. As our company grows-in fact, to help the company grow-I have no choice. We’re lucky at IHS to have a group of developers who do a great job at .NET development and SQL Server. And occasionally I still get to add my two cents.

Doug: In managing technical people, do you think that having a strong technical background is an advantage or a disadvantage?

Jim: I think it’s critical for building credibility and earning the respect of your staff. It has been my experience that non-technical managers don’t do a very good job of managing technical staff.

Doug: What sort of work are you doing these days?

Jim: We’re converting a number of PC applications to web-based systems using C# and SQL Server. We’re also exposing the logic of some of our systems as web services. The healthcare industry is generally not an early adopter of new technology, so I’m happy to see more interest in web services, since it fits our model well.

Doug: Have you read any good database-related or programming books lately?

Jim: I’m almost embarrassed to say that I haven’t read any programming books lately, but if Kalen Delaney does an Inside Microsoft SQL Server 2005 version, I’ll definitely read that.

Doug: I know you are a T-SQL sort of guy, so if you were still doing database work, how often do you imagine you would use C# or VB.NET for stored procedures and triggers?

Jim: Not very often, frankly. I’ve read the arguments for and against it, and I think it may be applicable in specific situations, but I’d still prefer to put the logic in components on a separate box.

Doug: What music do you listen to these days?

Jim: As my life gets busier, finding the time to discover new music gets harder. So I stick with some of my personal, if unusual, favorites: Marshall Crenshaw, The Smithereens, Paul Westerberg, and Buffalo Tom.

Do you know someone who deserves to be a Database Geek of the Week? Or perhaps that someone is you? Send me an email at editor@simple-talk.com and include “Database Geek of the Week suggestion” in the subject line.